For the purposes of TOGAF 9, the release notes provided in this chapter apply.
What's New in TOGAF 9?
This section provides an overview of the major new features within TOGAF 9.
Modular Structure
One focus of TOGAF 9 development has been to ensure that the specification content is structured in a modular way. The
modular seven-part structure of TOGAF allows for the concepts in each part to be developed with limited impacts on
other parts. Content that was contained within the TOGAF 8.1.1 Resource Base has been classified and moved into parts
that have a defined purpose (as opposed to generic "resources").
The modular structure in TOGAF is intended to support greater usability, as each part has a defined purpose and can be
read in isolation as a stand-alone set of guidelines. The modular structure is also expected to support incremental
adoption of the TOGAF specification. Finally, the modular structure supports more sophisticated release management of
the TOGAF specification. In future, individual parts may evolve at different speeds and the current specification
structure is intended to allow changes in one area to take place with limited impacts across the specification.
Content Framework
A significant addition of new content to the TOGAF specification is the content framework. The TOGAF content framework
provides a detailed model of architectural work products, including deliverables, artifacts within deliverables, and
the architectural building blocks that artifacts represent. The intention of including a content framework within TOGAF
is to drive greater consistency in the outputs that are created when following an Architecture Development Method
(ADM).
The benefit of including a content framework applies at a number of levels. Firstly, within a single architecture
development initiative the content framework provides a comprehensive checklist of architecture outputs that could be
created and consequently reduce the risk of gaps within the final architecture deliverable set.
The second major benefit of inclusion of a content framework applies when attempting to integrate architectural work
products across an enterprise. The content framework is intended to be adapted and then adopted by an enterprise in
order to mandate standard architectural concepts, terms, and deliverables. If all architecture initiatives use the same
models for content, their outputs can be combined much more easily than in situations where each architect uses a
completely different approach.
Finally, a substantial benefit of the inclusion of a content framework within TOGAF is that it provides (for the first
time) a detailed open standard for how architectures should be described. The existence of this standard allows tools
vendors, product vendors, and service vendors to adopt consistent ways of working, which in turn will result in greater
consistency between architecture tools, better tool interoperability, more consistent reference architectures, and
better comparability between related reference architectures.
Extended Guidance on Adopting TOGAF within an Enterprise
Within larger organizations, the practice of enterprise architecture requires a number of individuals and teams that
work together on many architectures. Although each architecture will address a specific problem, in an ideal situation
architectures can be considered as a group in order to develop an overall integrated view of how the enterprise is
changing.
This version of TOGAF features an extended set of concepts and guidelines to support the establishment of an integrated
hierarchy of architectures being developed by teams that operate within an overarching architectural governance model.
In particular, the following concepts are introduced:
-
Partitioning: In order to develop architectures that have manageable levels of cost and complexity, it is
necessary to partition the enterprise into specific architectures. TOGAF discusses the concept of partitioning and
provides a variety of techniques and considerations on how to partition the various architectures within an
enterprise.
-
Architecture Repository: TOGAF provides a logical information model for an Architecture Repository, which
can be used as an integrated store for all outputs created by executing the ADM.
-
Capability Framework: This version of TOGAF provides a more structured definition of the organization,
skills, roles, and responsibilities required to operate an effective enterprise architecture capability. The new
TOGAF materials also provide guidance on a process that can be followed to identify and establish an appropriate
architecture capability.
Explicit Consideration of Architectural Styles, Including SOA and
Security Architecture
The new Part
III: ADM Guidelines and Techniques brings together a set of supporting materials that show in more detail how the
ADM can be applied to specific situations. The new guidelines discuss:
-
The varying uses of iteration that are possible within the ADM and when each technique should be applied
-
The linkages between the TOGAF ADM and Service Oriented Architecture (SOA)
-
The specific considerations required to address security architecture within the ADM
-
The various types of architecture development required within an enterprise and how these relate to one another
Additional ADM Detail
This version of the TOGAF specification includes more detailed information supporting the execution of the ADM.
Particular areas of enhancement are:
-
The Preliminary phase, which features extended guidance on establishing an enterprise architecture framework and
planning for architecture development. The extended Preliminary phase also provides pointers to the definition of a
governance model for architecture benefit realization and also discusses the linkage between TOGAF and other
management frameworks.
-
The Opportunities & Solutions phase and Migration Planning phase, which feature a more detailed and robust
method for defining and planning enterprise transformation, based on the principles of capability-based planning.
The Benefits of TOGAF 9
TOGAF 9 provides a wide-ranging set of revisions to the TOGAF specification. When combined, these edits seek to achieve
a set of objectives to improve the value of the TOGAF framework.
Greater Usability
A number of enhancements within TOGAF 9 support greater usability of the overall specification. Firstly, the modular
structure of the specification makes it easier for an architect to consider a specific aspect of the architecture
capability. In all areas, the specification seeks to add detail and clarity above and beyond previous TOGAF versions.
More Focus on Holistic Enterprise Change
TOGAF has a solid history in IT architecture, considering the ways in which IT can support enterprise change. However,
as TOGAF has grown in depth and maturity it has become a framework for managing the entire spectrum of change required
to transform an enterprise towards a target operating model. TOGAF 9 continues this evolution and incorporates a
broader perspective of change that allows enterprise architecture to be used to specify transformation across the
business, data, application, and technology domains.
More Consistency of Output
Previous versions of TOGAF focused on providing a consistent process for developing architectures. TOGAF 9 includes a
greatly enhanced consideration of architectural work products to ensure that a consistent process is used to produce
consistent outputs. The Architecture Content Framework provides a detailed model of the outputs to be created by the
ADM. Additionally, the Enterprise Continuum, Architecture Partitioning, and Architecture Repository sections provide
detailed guidance on how architectural deliverables can be scoped, governed, and integrated.
Mapping of the TOGAF 8.1.1 Structure to TOGAF 9
Listed below are the Parts of the TOGAF 8 specification. For each Part, a description is given to explain where the
TOGAF 8 content can be found within the current specification.
Part I: Introduction
The Introduction part of the TOGAF 8.1.1 specification has been used as the basis for creation of Part I: Introduction in TOGAF 9. The introduction to TOGAF 9 reflects the content of
TOGAF 9 rather than the content of TOGAF 8.1.1, and also features a number of enhancements to improve accessibility.
Part II: Architecture Development Method
The essence of the TOGAF 8.1.1 ADM has been retained in TOGAF 9. Part II: Architecture Development Method (ADM) within TOGAF 9 is structured along
similar lines to Part II of the TOGAF 8.1.1 document. TOGAF ADM phase inputs and outputs (Chapter 16 of TOGAF 8.1.1)
have been moved from the ADM section of TOGAF 8.1.1 to Part IV: Architecture Content Framework of TOGAF 9.
TOGAF 9 ADM features additional content in the majority of ADM phases, which in the most part adds further detail and
clarification to the same approach that was described in TOGAF 8.1.1.
Part III: Enterprise Continuum
The TOGAF 8.1.1 Enterprise Continuum has seen a substantial degree of change. The Enterprise Continuum concept is
retained within Part V: Enterprise Continuum & Tools. The TOGAF Technical Reference Model and
Integrated Information Infrastructure Reference Model are extracted and placed within Part VI: TOGAF Reference Models in TOGAF 9.
TOGAF 9 adds new materials that describe an approach to architecture partitioning and also provides a structured model
of an Architecture Repository. These concepts support and elaborate on the original intent of the Enterprise Continuum.
TOGAF 9 removes the Standards Information Base from the TOGAF specification. However, an example SIB remains at The
Open Group web site (www.opengroup.org).
The concept of a Standards Information Base is still important within TOGAF, but the breadth and speed of change of
relevant architectural standards mean that it is impractical to maintain a current and relevant collection of standards
within a specification such as TOGAF.
Part IV: Resource Base
The Resource Base is not included in this version of TOGAF. Some elements of the Resource Base have been deprecated
from the TOGAF specification, but will still be available in White Paper form. Other elements of the Resource Base have
been moved to other areas of the specification.
The following table illustrates where TOGAF 8.1.1 Resource Base content can now be located.
Mapping of TOGAF 9 Structure to TOGAF 8.1.1
The following table illustrates where TOGAF 9 chapters map to those of TOGAF 8.1.1:
TOGAF 9 Chapter
|
Derivation from TOGAF 8.1.1
|
|
Part I: Introduction
|
|
1
|
Introduction
|
Material revised; based on Chapter 1
|
2
|
Core Concepts
|
New chapter
|
3
|
Definitions
|
Material derived from Chapter 36, reworked into formal definitions and abbreviations sections
|
4
|
Release Notes
|
New chapter
|
|
Part II: Architecture Development Method
|
|
5
|
Introduction
|
Material revised; based on Chapter 3
|
6
|
Preliminary Phase
|
Material revised; based on Chapter 4
|
7
|
Phase A: Architecture Vision
|
Material revised; based on Chapter 5
|
8
|
Phase B: Business Architecture
|
Material revised; based on Chapter 6
|
9
|
Phase C: Information Systems Architectures
|
Material revised; based on Chapter 7
|
10
|
Phase C: Data Architecture
|
Material revised; based on Chapter 8
|
11
|
Phase C: Application Architecture
|
Material revised; based on Chapter 9
|
12
|
Phase D: Technology Architecture
|
Material revised; based on Chapter 10
|
13
|
Phase E: Opportunities & Solutions
|
Material revised; based on Chapter 11
|
14
|
Phase F: Migration Planning
|
Material revised; based on Chapter 12
|
15
|
Phase G: Implementation Governance
|
Material revised; based on Chapter 13
|
16
|
Phase H: Architecture Change Management
|
Material revised; based on Chapter 14
|
17
|
ADM Architecture Requirements Management
|
No material change; maps to Chapter 15
|
|
Part III: ADM Guidelines and
Techniques
|
|
18
|
Introduction
|
New chapter
|
19
|
Applying Iteration to the ADM
|
New chapter
|
20
|
Applying the ADM at Different Enterprise Levels
|
New chapter
|
21
|
Security Architecture and the ADM
|
New chapter; derived from Security White Paper (W055)
|
22
|
Using TOGAF to Define & Govern SOAs
|
New chapter
|
23
|
Architecture Principles
|
No material change; maps to Chapter 29
|
24
|
Stakeholder Management
|
New chapter
|
25
|
Architecture Patterns
|
No material change; maps to Chapter 28
|
26
|
Business Scenarios
|
No material change; maps to Chapter 34
|
27
|
Gap Analysis
|
New chapter; derived from Gap Analysis
|
28
|
Migration Planning Techniques
|
New chapter
|
29
|
Interoperability Requirements
|
New chapter
|
30
|
Business Transformation Readiness Assessment
|
New chapter
|
31
|
Risk Management
|
New chapter
|
32
|
Capability-Based Planning
|
New chapter
|
|
art IV: Architecture Content Framework
|
|
33
|
Introduction
|
New chapter
|
34
|
Content Metamodel
|
New chapter
|
35
|
Architectural Artifacts
|
Derived from Chapter 31, plus new material
|
36
|
Architecture Deliverables
|
Revised; was Chapter 16
|
37
|
Building Blocks
|
Revised from Chapter 32
|
|
Part V: Enterprise Continuum &
Tools
|
|
38
|
Introduction
|
New chapter
|
39
|
Enterprise Continuum
|
Derived from Chapters 17 and 18 with substantial revisions
|
40
|
Architecture Partitioning
|
New chapter
|
41
|
Architecture Repository
|
New chapter
|
42
|
Tools for Architecture Development
|
No material change; maps to Chapter 38
|
|
Part VI: TOGAF Reference
Models
|
|
43
|
Foundation Architecture: Technical
Reference Model
|
No material change; maps to Chapters 19 and 20
|
44
|
Integrated Information Infrastructure
Reference Model
|
No material change; maps to Chapter 22
|
|
Part VII: Architecture Capability
Framework
|
|
45
|
Introduction
|
New chapter
|
46
|
Establishing an Architecture Capability
|
New chapter
|
47
|
Architecture Board
|
Minimal change; maps to Chapter 23
|
48
|
Architecture Compliance
|
Minimal change; maps to Chapter 24
|
49
|
Architecture Contracts
|
Minimal change; maps to Chapter 25
|
50
|
Architecture Governance
|
Minimal change, maps to Chapter 26
|
51
|
Architecture Maturity Models
|
Minimal change; maps to Chapter 27
|
52
|
Architecture Skills Framework
|
Some cosmetic changes; maps to Chapter 30
|
A
|
Glossary of Supplementary Definitions
|
Derived from Chapter 36
|
B
|
Abbreviations
|
Derived from Chapter 36
|
Using TOGAF
Conditions of Use
The TOGAF documentation is freely available for viewing online without a license. Alternatively, the complete TOGAF
documentation set may be downloaded and stored under license, as explained on the TOGAF information web site.
In either case, the TOGAF documentation may be used freely by any organization wishing to do so to develop an
architecture for use within that organization. No part of it may be reproduced, stored in a retrieval system, or
transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, for any other
purpose including, but not by way of limitation, any use for commercial gain, without the prior permission of the
copyright owners.
How Much Does TOGAF Cost?
The Open Group operates as a not-for-profit consortium committed to delivering greater business efficiency by bringing
together buyers and suppliers of information systems to lower the barriers of integrating new technology across the
enterprise. Its goal is to realize the vision of Boundaryless Information Flow.
TOGAF is a key part of its strategy for achieving this goal, and The Open Group wants TOGAF to be taken up and used in
practical architecture projects, and the experience from its use fed back to help improve it.
The Open Group therefore publishes TOGAF on its public web server, and allows and encourages its reproduction and use
free-of-charge by any organization wishing to use it internally to develop an enterprise architecture. (There are
restrictions on its commercial exploitation, however; see Conditions of Use)
Downloads
Downloads of the TOGAF documentation, including a printable PDF file, are available under license from the TOGAF
information web site (refer to www.opengroup.org/architecture/togaf). The license is free to any organization wishing
to use TOGAF entirely for internal purposes (for example, to develop an enterprise architecture for use within that
organization).
Why Join The Open Group?
Organizations wishing to reduce the time, cost, and risk of implementing multi-vendor solutions that integrate within
and between enterprises need The Open Group as their key partner.
The Open Group brings together the buyers and suppliers of information systems worldwide, and enables them to work
together, both to ensure that IT solutions meet the needs of customers, and to make it easier to integrate IT across
the enterprise.
TOGAF is a key enabler in this task.
Yes, TOGAF itself is freely available. But how much will you spend on developing or updating your enterprise
architecture using TOGAF? And how much will you spend on procurements based on that architecture?
The price of membership of The Open Group is insignificant in comparison with these amounts.
In addition to the general benefits of membership, as a member of The Open Group you will be eligible to participate in
The Open Group Architecture Forum, which is the development program within which TOGAF is evolved, and in which TOGAF
users come together to exchange information and feedback.
Members of the Architecture Forum gain:
-
Immediate access to the fruits of the current TOGAF work program (not publicly available until publication of the
next edition of the TOGAF document) - in effect, the latest information on TOGAF
-
Exchange of experience with other customer and vendor organizations involved in enterprise architecture in general,
and networking with architects using TOGAF in significant architecture development projects around the world
-
Peer review of specific architecture case study material
|